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Abstract 

A new format for standardizing common view time transfer data , recommended by the Consul- 
tative Committee for the Definition of the Second , is being implemented in receivers commonly used 
for contributing data for the generation of International Atomic Time. We discuss three aspects of 
this new format that potentially improve GPS common-view time transfer: (1) the standard specifies 
the method for treating short term data , (2) it presents data in consistent formats including needed 
terms not previously available , and (3) the standard includes a header of parameters important for 
the GPS common-view process . In coordination with the release of firmware conforming to this 
new format the Bureau International des Poids et Mesures will release future international track 
schedules consistent with the new standard. 


INTRODUCTION 

A new format for standardizing common view time transfer data, recommended by the Consul- 
tative Committee for the Definition of the Second (CCDS), is being implemented in receivers 
commonly used for contributing data for the generation of International Atomic Time (TAI). 
The primary means of remote clock comparison for generating TAI is common-view GPS time 
transferal . The global accuracy for this type of time transfer is currently less than 10 ns I 2 1 
. Understanding the sources of inaccuracy, the BIPM initiated an effort to standardize data- 
taking methods used in receivers and data transfer methods used for reporting to the BIPM. 
By combining this effort with the use of good coordinates, precise GPS satellite ephemerides, 
and measured local ionospheric delays, we hope to increase the accuracy for common-view 
time transferal . 

One of the major motivations for standardization is the implementation of Selective Availability 
(SA) in GPS satellites. With SA, GPS timing is degraded as a way of limiting the navigation 
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accuracy available to the standard positioning service (SPS) user. This follows since navigation 
in GPS is accomplished using measurements of time as received from satellites. If common-view 
time transfer is performed strictly, that is, with measurements taken on identical seconds, and 
with receivers which process the signals and the data identically, then the GPS satellite clocks 
cancel completely. SA makes this need for strict common-view even more important. We 
include in this paper some direct satellite data with SA and predict the effects on common— view 
time transfer due to differences in receivers. Thus, a standard can improve time transfer by 
allowing common— view time transfer to be done with different receivers and still cancel the 
effects of the satellite clock. 

The new format has potential to improve GPS common-view time transfer due to a number 
of elements: (1) the standard specifies the method for treating short term data, (2) it presents 
data in consistent formats including needed terms not previously available, and (3) includes a 
header of parameters important for the GPS common-view process. Essential to common-view 
time transfer is that stations track satellites according to a common schedule. In coordination 
with the release of firmware conforming to this new format the Bureau International des Poids 
et Mesures (BIPM) will release future international track schedules consistent with the new 
standard. In this paper we summarize information about the short-term data processing, the 
header and the data format. When developing the standard for a receiver, one should obtain 
all the detailed information as reported in the Technical Directives! 2 3 4 5 ! . 

SHORT TERM DATA PROCESSING 

Data processing is performed as follows: 

1 . Pseudo-range data are recorded for times corresponding to successive dates at intervals of 
Is. The date of the first pseudo-range data is the nominal starting time of the track. It is 
referenced to UTC and appears in the data file under the acronyms MJD and STTIME. 

2. Least-squares quadratic fits are applied on successive and nonoverlapping sets of 15 
pseudo— range measurements taken every second. The quadratic fit results are estimated 
at the date corresponding to the midpoint of each set. 

3. Corrections are applied to the results of (2) to obtain estimates of the local reference 
minus the Satellite Vehicle (SV) clock (REFSV) and of the local reference minus GPS 
time (REFGPS) for each 15 second interval. 

4. The nominal track length corresponds to the recording of 780 short-term measurements. 
The number of successive and nonoverlapping data sets treated according to (2) and (3) 
is then equal to 52. For full tracks, the track length TRKL will thus equal 780 s. 

5. At the end of the track, least-squares linear fits are performed to obtain and store the 
midpoint value and slope for both REFSV and REFGPS. Since these two are related 
deterministically by nearly a straight line they will have the same rms deviation around 
the fit, which is also stored as DSG. In addition, least— squares linear regression gives the 
midpoint and slope of the ionospheric and tropospheric model values, and the ionospheric 
measurements if they exist. 
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THE EFFECTS OF SA 


We investigate the effects of SA by taking measurements every 15 s of GPS - UTC(NIST) 
tracking different satellites from horizon to horizon. We took data sequentially from three 
different satellites on two consecutive days, November 21-22, 1994. The satellites had pseudo- 
random code numbers (PRN’s) 20, 22, and 25. Figures 1-3 show the data from the three 
satellites, and Figures 4-6 show the time deviation TDEV of the three, respectively. 

The new standard will cancel all the clock dither when used for common-view GPS time 
transfer, provided that each of the two receivers involved track the same satellites over the 
same time periods. If there is a difference of 15 s in the tracking, for example if one receiver 
tracks 15 s less than the other, then the clock dither of SA will corrupt the common-view time 
transfer. We can estimate this by looking at the expected dispersion in time at due to SA at 15 
s. The rms of the three TDEV values for r=15 s is 11 ns. From the TDEV plots we see that 
the slope on the log-log plots starts consistent with a model of r° from 15-30 s. If we assume 
a model of flicker phase modulation (PM) for r=15 s this implies an expected time dispersion 
of 13 nsl 5 ! . Over a 13 min track there are 52 estimates of REFGPS and REFSV each from a 
quadratic fit over 15 s of data. Let us consider the case where one track is a full-length track 
and the matching track in another receiver is 15 s short. If we can assume that the effects of 
one 15 s point average down in the linear fit as the square root of the total number of points, 
then we can expect the effect on the common-view time transfer to be 


1 3 ns 


= 1.8 ns. 


( 1 ) 


Thus SA could add approximately 2 ns to a common-view uncertainty budget with only a 
mis-match of 15 s from exact common-view. With a goal of 1 ns we see the reason why a 
standard for data taking can help common-view time transfer. 

Many users receive GPS time directly from the satellites without using the common-view 
method to compare with another lab. From considering the TDEV of SA, we can design a 
filter that averages SA optimally, to allow users to obtain the best possible restitution of GPS 
timel 6 ! . From the three TDEV analyses we see a bump rising from 1 min and dropping at 16 
min. This effect could be due in part to a periodic behavior with a period of approximately 16 
minf 7 l,8 . Averaging can improve the GPS restitution if the TDEV values drop with increasing 
< insert 4>. Yet there is no indication in these data that the TDEV values drop significantly 
beyond 16 min. This may be due to effects at the beginning and end of the tracks when the 
elevation is low. This suggests limitations on the potential for filtering SA. Yet our data were 
taken using a single channel receiver. A multi-channel receiver could improve on filtering. It 
may be that the combination of SA signals still drop in TDEV, allowing improvement from 
averaging. 


THE DATA FORMAT 

The data format consists of: 
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1. a file header with detailed information on the GPS equipment, 

2. a line header with the acronyms of the reported quantities, 

3. (3) a unit header with the units used for the reported quantities, 

4. (4) a series of data lines, one line corresponding to one GPS track. The GPS tracks 
are ordered in chronological order, the track reported in line n occurring after the track 
reported in line (n-1). Each line of the data file is limited to 128 columns and is terminated 
by a carriage-return and a line feed. The format for one line of data can be represented 
as follows: 


No measured ionospheric delays available 

0000000000000000000000000000000000000000000000 
00000000011 1111111 1222222222233333333334444444 
1234567890123456789012345678901234567890123456 
PRN*CL**MJD**STTIME*TRKL*ELV*AZTH***REFSV***** 
*************hhininss**s** . ldg* . ldg**** . Ins***** 

*12* 12* 12345* 12 12 12* 1234* 123* 1234*+ 1234567890* 

0000000000000000000000000000000000000000000000000000011 
4445555555555666666666677777777778888888888999999999900 
7890123456789012345678901234567890123456789012345678901 
*SRSV*****REFGPS****SRGPS**DSG*I0E*MDTR*SMDT*MDI0*SMDI* 
. lps/s***** . Ins**** . lps/s* . Ins***** . Ins . lps/ s . Ins . lps/ s 
+12345*+ 1234567890*+ 12345 *1234* 123* 1234*+ 123* 1234*+ 123* 

111111111111111111111111111 
00000000111 11111 11222222222 
234567890123456789012345678 
CK 
** 

12optionalcoimen.tsoption.alc 


Measured ionospheric delays available 

0000000000000000000000000000000000000000000000 
0000000001 1111111 11222222222233333333334444444 
1234567890123456789012345678901234567890123456 
PRN*CL**MJD**STTIME*TRKL*ELV*AZTH***REFSV***** 
*************hhrnrnss**s** . ldg* . ldg**** . Ins***** 
*12* 12* 12345* 12 12 12* 1234* 123* 1234*+ 1234567890* 
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0000000000000000000000000000000000000000000000000000011 
4445555555555666666666677777777778888888888999999999900 
7890123456789012345678901234567890123456789012345678901 
*SRSV*****REFGPS****SRGPS**DSG*IOE*MDTR*SMDT*MDIO*SMDI* 
. lps/ s***** . ins**** . lps/s* . ins***** . Ins . lps/ s . Ins . lps/s 
+12345*+ 1234567890*+ 12345* 1234* 123* 1234*+ 123* 1234*+ 123* 

111111111111111111111111111 
000000001111111111222222222 
234567890123456789012345678 
MSIO*SMSI*ISG*CK 
. Ins. lps/s . Ins** 

1 234*+ 123* 123* 12opt comments 


The following is an example of what the data looks like, using fictitious data. 


Example (fictitious data) 

GGTTS GPS DATA FORMAT VERSION = 01 
REV DATE = 1993-05-28 
RCVR = ADA TTR7A 12405 1987 14 
CH = 15 

IMS = 99999 or IMS = AIR NIMS 003 1992 

LAB = XXXX 

X = +4327301.23 m 

Y = +568003.02 m 

Z = +4636534.56 m 

FRAME = ITRF88 

COMMENTS = NO COMMENTS 

INT DLY = 85.5 ns 

CAB DLY = 232.0 ns 

REF DLY = 10.3 ns 

REF = 10077 

CKSUM = C3 or CKSUM = 49 
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No measured ionospheric delays available 

PRN CL MJD STTIME TRKL ELV AZTH REFSV SRSV REFGPS SRGPS DSG 

IOE MDTR SMDT MDIO SMDI CK 


hhmmss s . ldg . ldg ,1ns .lps/s .Ins .lps/s -Ins .lns.lps/s 


3 

8D 48877 

20400 

780 

251 

3560 

-3658990 

+ 100 

+4520 

+ 100 

21 

221 

64 

+90 

-27 

18 

BBhello 
02 48877 

35000 

780 

650 

910 

+56987262 

-5602 

+5921 

-5602 

350 

123 

102 

+61 

281 

15 

+26 52 
11 48878 

110215 

765 

425 

2700 

+45893 

+4892 

+4269 

+4890 

306 

55 

54 

-32 

+ 15 
15 

A9 

88 48878 

120000 

780 

531 

2850 

+45992 

+4745 

+4290 

+4745 

400 

55 

57 

-29 


+16 18receiv. out of operation 
Measured ionospheric delays available 


PRN 

CL MJD STTIME TRKL ELV AZTH 

REFSV 

SRSV 

REFGPS 

SRGPS 

DSG 




IOE 

MDTR SMDT MDIO SMDI MSIO SMSI 
hhmmss s . ldg . ldg 

ISG CK 
. Ins 

. lps/s 

. Ins 

. lps/s 

. Ins 




. Ins 
3 

. . lps/s . Ins . lps/s . Ins . lps/ s . Ins 
8D 48877 20400 780 251 3560 

-3658990 

+ 100 

+4520 

+ 100 

21 

221 

64 

+90 

-27 

18 

480 -37 18 F4hello 

02 48877 35000 780 650 910 

+56987262 

-5602 

+5921 

-5602 

350 

123 

102 

+61 

281 

15 

+26 9999 9999 999 89no meas ion 
11 48878 110215 765 425 2700 +45893 

+4892 

+4269 

+4890 

306 

55 

54 

-32 

+ 15 
15 

599 +16 33 29 

88 48878 120000 780 531 2850 

+45992 

+4745 

+4290 

+4745 

400 

55 

57 

-29 


+16 601 +17 29 OOrec out 
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The definitions of the acronyms used in the data format follow. Note that a * stands for a 
space, ASCII value 20 (hexadecimal). Text to be written in the data file is indicated by ’ ’. 

File header 

Line 1: ’GGTTS*GPS*DATA*FORMAT*VERSION* = *01, title to be written. 

Line 2: REV*DATE* = *’ YYYY’-’MM’-’DD, revision date of the header data, changed when 1 
parameter given in the header is changed. YYYY-MM-DD for year, month and day. 

Line 3: ’RCVR* = *’ MAKER’*’TYPE’*’SERIAL NUMBER’*’ YEAR’*’, maker acronym, type, 
serial number, first year of operation, and eventually software number of the GPS time 
receiver. 

Line 4: ’CH* = *’ CHANNEL NUMBER, number of the channel used to produce the data included 
in the file, CH = 01 for a one-channel receiver. 

Line 5: ’IMS* = *’ MAKER’*’TYPE’*’SERIAL NUMBER’*’YEAR’*\ maker acronym, type, serial 
number, first year of operation, and eventually software number of the Ionospheric 
Measurement System. IMS = 99999 if none. 

Line 6: ’LAB* = *’ LABORATORY, acronym of the laboratory where observations are performed. 

Line 7: ’X* = *’ X COORDINATE ’*m’, X coordinate of the GPS antenna, in m and given with 
at least 2 decimals. 

Line 8: ’Y* = *’ Y COORDINATE ’*m’, Y coordinate of the GPS antenna, in m and given with 
at least 2 decimals. 

Line 9: ’Z* = *’ Z COORDINATE ’*m’, Z coordinate of the GPS antenna, in m and given with 
at least 2 decimals. 

Line 10: ’FRAME* = *’ FRAME, designation of the reference frame of the GPS antenna coordi- 
nates. 

Line 11: ’COMMENTS* = *’ COMMENTS, Any comments about the coordinates, for example the 
method of determination or the estimated uncertainty. 

Line 12: ’INT*DLY* = *’ INTERNAL DELAY ’*ns’, internal delay entered in the GPS time receiver, 
in ns and given with 1 decimal. 

Line 13: ’CAB*DLY* = *’ CABLE DELAY ’*ns’, delay coming from the cable length from the 
GPS antenna to the main unit, entered in the GPS time receiver, in ns and given with 1 
decimal. 

Line 14: ’REF*DLY* = *’ REFERENCE DELAY ’*ns’, delay coming from the cable length from 
the reference output to the main unit, entered in the GPS time receiver, in ns and given 
with 1 decimal. 
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Line 15: ’REF* = *’ REFERENCE, identifier of the time reference entered in the GPS time 
receiver. For laboratories contributing to TAI it can be the 7-digit code of a clock or the 
5-digit code of a local UTC, as attributed by the BIPM. 

Line 16: ’CKSUM* = *’ XX, header check-sum: hexadecimal representation of the sum, modulo 
256, of the ASCII values of the characters which constitute the complete header, beginning 
with the first letter ’G’ of ’GGTTS’ in Line 1, including all spaces indicated as * and 
corresponding to the ASCII value 20 (hexadecimal), ending with the space after ’ = ’ of 
Line 16 just preceding the actual check sum value, and excluding all carriage returns or 
line feeds. 

Line 17: blank line. 
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Acronyms 


The following are the defintions of the acronyms 


PRN: 

CL: 

MJD: 

STTIME: 

TRKL: 

ELV: 

AZTH: 

REFSV: 

SRSV: 

REFGPS: 

SRGPS: 

DSG: 

IOE: 

MDTR: 

SMDT: 

MDIO: 

SMDI: 

MSIO: 

SMSI: 

ISG: 

CK: 


Satellite vehicle PRN number. 

Common-view hexadecimal class byte. 

Modified Julian Day. 

Date of the start time of the track in hour, min and second referenced to UTC. 
Track length, 780 for full tracks, in s. 

Satellite elevation at the date corresponding to the midpoint of the track in 0.1 
degree. 

Satellite azimuth at the date corresponding to the midpoint of the track in 0.1 
degree. 

Estimate of the time difference of local reference minus SV clock at the middle 
of track from the linear fit, in 0.1 ns. 

Slope of the linear fit for REFSV 0.1 ps/s. 

Estimate of the time difference of local reference minus GPS time at the middle 
of the track from the linear fit, in 0.1 ns. 

Slope of the linear fit for REFGPS 0.1 ps/s. 

[Data Sigma] Root mean square of the residuals to the linear fit for REFGPS 
in 0.1 ns. 

[Index of Ephemeris] Three digit decimal code (0-255) indicating the ephemeris 
used for the computation. 

Modelled tropospheric delay at the middle of the track from the linear fit, in 0.1 
ns. 

Slope of the modelled tropospheric delay resulting from the linear fit in 0.1 ps/s. 
Modelled ionospheric delay resulting from the linear in 0.1 ns. 

Slope of the modelled ionospheric delay resulting from the linear fit in 0.1 ps/s. 
Measured ionospheric delay resulting from the linear fit in 0.1 ns. 

Slope of the measured ionospheric delay resulting from the linear in 0.1 ps/s. 
[Ionospheric Sigma] Root mean square of the residuals to the linear fit in 0.1 ns. 
Data line check-sum: hexadecimal representation of the sum, modulo 256, of 
the ASCII values of the characters which constitute the data line, from column 
1 to space preceeding the check-sum. (both included). There can be optional 
comments on the data line after the check sum out to the 128 character line 
length. These characters are not included in the line check-sum. 


CONCLUSIONS 

The new GPS data format, along with the prescription for processing short term data, can help 
improve common— view time transfer. Especially with the implementation of SA, common— view 
tracks can be significantly degraded if the two receivers tracking in common view do not work 
identically. The new standard can help us move toward a goal of 1 ns time transfer accuracy 
across intercontinental distances using GPS time transfer in common-view. 
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QUESTIONS AND ANSWERS 


DAVID ALLAN (ALLAN’S TIME): I would like to just highlight the importance of the 
paper you presented on this new standard. Just to tell everybody, we believe, as we go through 
the theory of all the errors in common view, that with this new standard that an accuracy of 
one ns is achievable. To date, only about four ns has been documented just by way of where 
we are versus where we think the standard can take us. So I think it’s very important work for 
the operational aspects, for clock input to TAI and UTC. So thank you for sharing it with us. 

The other point that I would like to make is on the TDEV plot, that it is not a necessary and 
sufficient condition that if you have a hump in the data that it’s due to a periodic event. There 
are at least two, and probably more, basic processes in the essay spectrum, and if one looks 
at longer-term data, in fact, this is confirmed; and there is not necessarily just the 60-minute 
type periodic phenomena. It’s really two pretty much separate parallel processes; and, in fact, 
period modeling is not the best model that one would want to use. 

I simply want to point out that it’s not a necessary and sufficient condition, given a hump, that 
there is a periodic event. 

M.J. VANMELLE (ROCKWELL): A couple of things. The rubidium is on 20 and not on 
25. So it’s hard to tell between rubidiums and cesiums there. 

Also, did you ever do the experiment on the satellites that don’t have SA on them, like number 
ten? Do you get that same two ns error with 15 seconds separation? 

MARC A. WEISS (NIST): No, it’s lower. I’m sorry, at 15 seconds, I’m not sure. There 
should be very short-term — - I’m not sure what we were trying. 

HAROLD CHADSEY (USNO): A quick question for you. You were talking about the fact 
that when you do the common view that everything drops out. What about geometrical effects? 
Also, the fact that speed of the wave is not constant through the atmosphere, and you’ll be 
effected more through a thick atmosphere than through a small atmosphere? 

MARC A. WEISS (NIST): What I said that the effects of Selective Availability cancel 
completely if you do exact common- view time transfer and use a post-process ephemeris. Of 
course, the effects of ionosphere and troposphere are still there. Those need to be dealt with. 
The ionosphere, by measuring, and the troposphere can be helped also with measurements. 
They need to be if we’re going to get the best we can. 

GERNOT M. WINKLER (USNO): I think the time has come to start a little controversy, 
because we are all too peaceful down here. You have somehow attacked obliquely one of the 
tenants of my gospel which I have been preaching for 10 years. That is the melting pot method 
can average out by having a sufficient amount of data — it can average out the effects of 
Selective Availability. Your comment was that you cannot be sure that biases are averaging 
out. 

I want to remind you that the common view — - that’s true; I mean, the common view cancels 
the effect of Selective Availability; but in the Selective Availability, the satellites themselves are 
not correlated; and the noise, which is superimposed, is strictly bounded. So if you have these 
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conditions and a sufficient amount of data collection, you completely suppress the individual 
noise. It just depends on how much data you need. And it turns out that if you have an 
eight-channel receiver and you average about six hours, that you cannot distinguish the resulting 
time transfer data from what we obtain with the keyed receiver. 

The great advantage of a melting-pot method, compared to the common view, is that it is a 
robust method. You obtain perfection just commensurate with the effort that you have. You 
have internal checks on the result which you have, because we have a statistic of the variations. 
In a case of the common view, you have nothing. We know that in practice your one ns or two 
ns accuracy cannot be achieved. The question is, how do you check operation in an automatic 
system? How do you check that you really can rely on a single data point in comparison to 
the melting pot where you always have lots of data? Whatever happens, it will produce an 
outlier which is rejected. 

So, I wanted to bring that out because there is a great difference in the basic philosophy. In 
the common view, theoretically you have a superior method; but in practice, I maintain there 
are weaknesses; and do you lack a measure of performance as compared to the melting-pot 
method where you have everything you need? Do you have really a robust method which 
protects you against outliers of whatever magnitude in fact? 

MARC A. WEISS (NIST): I would like to respond to that. Thank you, Dr. Winkler. I 
know for years now we’ve had differences on this. It’s going to wake people up a little bit. One 
point is that we don’t have only a point in common view. We can do pretty much everything 
with common view that you do with a melting pot, and more. That with the melting pot, if 
you have a eight-channel receiver at two locations, then why not take the eight channels of 
data simultaneously at the two locations and cancel all the effects of SA, and then use robust 
statistics on the resulting data where all the biases have been cancelled, and all that’s left is 
the noise? So I think all the statistics that you do with melting pot are still there with common 
view. 

The other thing is that because data are bounded does not in itself imply that averaging brings 
you down to a single correct number. It may, in fact — - I don’t doubt that it has worked on 
many occasions; but simply saying that they’re bounded does not — - there’s no reason that it 
should average down correctly. 

GERNOT M. WINKLER (USNO): But we have a check, because you look at the distribution 
of your measurement points. On that you simply add all that area, which we have to do to 
obtain the competence of that area. 

MARC A. WEISS (NIST): I don’t agree with that. You can have all the data averaging 
down to the wrong number. I understand that that is not what you’ve found by doing it. But 
there’s no guarantee that that always will happen. 

CLAUDINE THOMAS (BIPM): Of course, I will have some words. For TAI, we have 46 
contributing laboratories, I mean, laboratories keeping local UTC; and most of them are using 
OPS now. First of all, all of these laboratories, except maybe USNO, have only one channel 
CA code receiver. That is to say, except for USNO, no one has one channel receivers which 
are given reliable measurements. So obviously, we have no data to do the measurements at 
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the present time. Maybe it will come, but that’s not the case for the moment. That’s the first 
point. 

The second point is that view of the BIPM for the computation of TAI has always been to try 
to reduce errors in the physical phenomena which are invoked; for instance, for the ionospheric 
delay, we like to use measured ionospheric delays as they are labelled. For the position of the 
satellite, we like to use precise satellite ephemerides. For the antenna coordinates, huge work 
was done some years ago by my colleague, Dr. Lewandowski (he can speak about that) in 
which he found accurate positions for the antennas. So we have always tried to phase all our 
sources and trying to reuse them. That was our viewpoint and that is what we did until now. 
That was the way we worked. 

The last point, of course, common-view time transfer is done, it’s computed. To find time 
difference between two local UTCs, we have a range, of course, for a long-distance time link, 
like between NIST and OP; we have a range common view for, let’s say, two or three days. So 
we have some kind of average of course. For a smaller distance, like between Paris and PTB, 
Germany, we have a range, let’s say, of less than one day. So that is to say we have some kind 
of average too. 

I would say that what we are doing at the present time is the best we can do with the data we 
have. 

RICHARD KEATING (USNO): You’ve stated that with common view, you’re eliminating 
all these errors. I assume that’s because of symmetry. But that’s a theoretical position. When 
you get down to actual practice, reality doesn’t always follow theory. I just have to ask you, 
how confident are you that you have no biases in common view? Can you really say that you 
can average and you are not getting any biases? 

MARC A. WEISS (NIST): Well what would a bias be due to? 

RICHARD KEATING (USNO): Well, for example, I’ll give you an example. I have seen 
estimates of precise ephemeris accuracies. They’ve ranged from anything from one meter to 20 
meters. There is a real possibility there that your precise ephemerides may not be as accurate 
and may contain real biases. 

MARC A. WEISS (NIST): I think that’s a good point in fact. Biases have to be due — - 
if you look at the common-view process, you have the satellite and then you have the ground 
stations on the earth; and then you have the atmosphere. So if you measure it exactly at 
the same time — - the only thing I’m claiming that cancels exactly is Selective Availability. In 
fact, the only thing I know for sure that cancels is clock dither. The ephemeris cancels to the 
extent that an error is perpendicular to the line between the satellites. If there is an error in 
the satellite position, it will add an error to common-view time transfer. And in fact, with 
precise ephemerides, prior to having the laser reflector, we had no way of knowing if they were 
accurate. They were simply consistent. 

Errors can also come in the atmosphere due to ionosphere and due to troposphere, due to 
multi-path at the stations, and due to coordinate errors. So all of those things can add errors. 
It’s going to be true whether you’re using melting pot or common view or anything. Those are 
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all in GPS. Whenever you do GPS, you’re concerned about ephemeris, ionosphere, troposphere, 
and multi-path, and coordinates. 

I think a point that I would really like to stress about that -- and I think your point is well 
made — - is that it’s the difference between accuracy and stability; that you can have numbers 
that agree perfectly, that are extremely well consistent and are consistently wrong. For example, 
if you took a commercial cesium clock -- and this is the difference between a commercial 
cesium and a laboratory primary standard. If you have a commercial cesium and it’s produced 
by a manufacturing technique, and there’s a millimeter error in the end-to-end phase shift in 
the cavity, all the clocks will have that; and they’ll all be off in frequency because of that, in 
exactly the same way; and all the other effects will average down and you’ll end up with a bias 
that does not average. 

That’s an example of the difference between stability and accuracy. I think we need to be very 
careful when we use the word “accuracy.” We’re not talking about something that you can 
average; we’re talking about something that you have to prove. 

GERNOT M. WINKLER (USNO): You’re example is making my point. How do you find 
out that all of these cesiums have a bias? 

MARC A. WEISS (NIST): You evaluate them. 

GERNOT M. WINKLER (USNO): You evaluate them and you look at the statistical 
distribution of what there frequencies are; and you compare them with a standard. You found 
out how it is. 

MARC A. WEISS (NIST): But you don’t compare with another standard. You evaluate 
them independently; you measure the effects through something that’s completely independent. 

CLAUDINE THOMAS (BIPM): There’s a very big question of the difference between 
stability, precision and accuracy of course. There were some fundamental and formal papers 
about that at the BIPM. We consider that an accuracy is characterized by an uncertainty given 
as a one sigma value which was from the quadratic sum of the different uncertainties which are 
estimated from the different sources of errors which appear within common-view time transfer. 
I have already at the BIPM tried to do that, and I think that we can estimate an uncertainty of 
about 10 ns, it’s eight to ten ns, one sigma for long-distant GPS common view, using precise 
satellite ephemerides from the IGS, and ionospheric measurements and with the hypotheses 
that the receivers themselves are correctly calibrated, which may not be the case; and which 
could add, of course, a bias. So let’s say eight to ten ns, one sigma as the accuracy of GPS 
common views. 
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Abstract 

At the beginning of 1994, field trials for an international two-way time transfer experiment 
using the INTELSAT V-A(F13) satellite at 307 oE were started. The experiment was set up to last 
one year and involved six European time laboratories and two North- American time laboratories. 
Three times a week, 5 -minute time transfer sessions were scheduled. At each of these laboratories, 
GPS common-view time observations were also performed. 

From September 22 to October 22, 1994 a calibration trip which visited participating laboratories 
in Europe was organized. It involved a portable Vertex 1.8 meter two-way station (Fly Away STation 
[FAST]), belonging to USNO, and a portable GPS time transfer receiver, belonging to BIPM. The 
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calibration trip was conducted by members of the staff of USNO and Observatoire de la Cote d’Azur 
( OCA). It provided differential delays of the satellite Earth stations and GPS receivers. The initial 
analysis of this calibration campaign are reported here. 


I. Introduction 

The TWSTT technique has developed the reputation of being one of the most accurate and 
precise methods for time transfer I 1 - 2 !. One of the goals of the FAST Calibration Trip was to 
evaluate the quality of this measurement technique. While quality implies a somewhat nebulous 
expression, attempts can be made to quantitatively express the quality of the technique as a 
function of its capability. Its capability being defined in terms of its accuracy and precision. 
Obviously, a technique, where the accuracy is identical to the precision of measurement, is a 
technique which has reached its full capability. This relation can be shown as. 

FULL CAPABILITY Accuracy = Precision 

If the accuracy of a measurement process is significantly less than its measurement precision 
than systematic errors are still affecting the process. The technique is, then, not yet of high 
quality. 

In regard to TWSTT, estimates for the inherent precision of measurement for this technique 
range from 100-500 ns. PI. It is possible to adopt 250 ps. as the current level of precision. 
Various estimates for the achievable accuracy range from 25 to 1 ns. This means that significant 
systematic errors are still affecting the results of TWSTT. It is the reason for undertaking 
this FAST Calibration Trip. It is hoped that, by careful measurements, more insight into the 
errors affecting T^VSTT will be gained. It is assumed that one of the factors contributing to 
this error is our inability to measure the delays that signals undergo as they pass through the 
spacecraft. This thought to be one of the greatest contributors to the systematic errors affecting 
the measurement process. 


II. FAST Calibration Trip 

With regard to calibrating or determining delays through a system, there are three approaches. 
One is to design and develop equipment which will inject a signal into the system and 
consequentially trace its path throughout the station. This is the approach of Gerrit de Jong at 
VSLIH. One can then take this calibration station around to different laboratories and measure 
the delays through other similar stations. This procedure could be called absolute calibration 
(AC). 

Another approach would be to measure the delays throughout a small portable station and 
then transport this station to other laboratories in order to make side— by— side measurements 
with the station to be calibrated. This approach could be called absolute system calibration 
(ASC). 

Still another approach would be to carry a transportable station around to different laboratories 
and make side-by-side measurements and refer all measurements to one primary reference 
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station. This is the approach adopted for this experiment since operational absolute calibration 
equipment has not yet been fully developed. This approach could be called relative system 
calibration (RSC) 

Planning for the FAST calibration started at the Second Meeting of the CCDS Working Group 
on TWSTT held at NPL on 22 October 1994f 5 l. 

III. Observational Plan 

The plan for RSC is rather simple. One makes initial measurements of the calibration 
station with respect to one fixed base station. A record of the difference is made. Similar 
measurements will be made at subsequent base stations and the differences also noted. At the 
same time, measurements are also made with respect to all other base stations participating in 
the experiment. Then, relative calibration with regard to any base station can be deduced. 

The observation sequence followed at each laboratory visited by the FAST Team consisted of 
making side-by-side measurements between the FAST and visited laboratory for at least half 
an hour. Next, the FAST and laboratory base station each did time transfers with all other 
participating labs. This observation period usually spanned several hours. Finally, The FAST 
made side-by-side observations with the visited laboratory base station before going on to the 
next laboratory. 

Also, at each base station, sufficient documentation of known, measured delays were made in 
order to correct for as many systematic offsets as possible. 


IV. Data Analysis 

The observed data obtained at VSL are presented in Tables 1, 2 and 3. Several consistency 
checks can be performed with this data. Because the FAST had not yet returned to its initial 
starting point at the time of the writing of this paper, a closure error or verification that nothing 
happened to the FAST during the trip has not yet been performed. 

An initial analysis that can be done is to set up a three cornered hat method to see if there 
is consistency among the readings [6], By differencing the data in Tables II and III, one can 
compute a value for the time difference between the FAST at VSL and the base station at 
VSL [FAST(VSL)— VSL(Base Station)]. These differences are given in Table IV. Next, one 
can compute the differences between the observed values for FAST(VSL)-VSL(Base Station) 
and the computed one. This is given in Table V. The data in Table V indicates that the two 
procedures agree to within about a nanosecond. 


V. Discussion 

The consistency check performed in Section IV points to another fact that has been the subject 
of some speculation. The data in Table I was obtained by going through the spot transponder 
on INTELSAT V-A (F13) which covers Europe. The data exhibited in Tables II and III was 
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obtained through the transponder which connects Europe to North America. Since the data 
measured for the difference between the FAST located at VSL and the VSL Base Station and 
the data computed from the set of measurements obtained using USNO as an intermediary 
is so close together, it seems that the delays through the different transponders are not that 
much different. This is not conclusively proven by this procedure. In any event, this is a 
notable observation. Once a permanent routine evolves in TWSTT, it is easy to visualize that 
data exchange may not always occur through the same transponders of the satellite being used. 
This observation merits further corroboration because it is a possible source contributing to the 
systematic errors of the measurement process. 


VI. Conclusions 

Preliminary analysis of some of the data obtained during the FAST Calibration Trip to Europe 
indicate that the equipment performed reasonably well. After additional data is obtained when 
the FAST is returned to USNO, it will be possible to verify this conclusion. It will also then be 
possible to establish a calibrated path between the stations which participated in the experiment. 
This will be an essential step to precede the next round of international time transfers. 
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Table I Observed Time Differences 
[FAST(VSL)— VSL(Base Station)] 

MJD 49625.52419 I 49626.35815 

Observed (FAST-VSL) | -667.28 ns | -669.31 ns. 

Table II Observed Time Differences 
[USNO(Base Station) - VSL(Base Station)] 
MJD 49624.62534 I 49626.48090 

Observed (USNO-VSL) | 122.13 ns. | 130.32 ns. 

Table III Observed Time Differences 
[USNO(Base Station) - FAST(VSL)] 

MJD 49624.62327 I 49626.46942 

Observed (USNO-FAST) | 790.14 ns. | 797.97 ns. 

Table IV Computed Time Differences 
[FAST(VSL)— VSL(Base Station)] 

MJD 49625 I 49626 

Computed (FAST-VSL) ] 668.01 ns. | 667.65 ns. 

Table V Observed-Computed Time Differences 
of FAST(VSL)- VSL(Base Station) 

MJD 49625 I 49626 

(O-C) FAST-VSL 0.73 ns. -1.67 ns. 
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PANEL DISCUSSION ON WORKSHOPS 


Moderator: Raymond L. Filler 
US Army Research Laboratory 


RAY FILLER: Welcome to Part II of the audience moderator discussion which occurred 
yesterday. Today we’re going to have our three session chairpersons (one is missing in action) 
give us a brief summary of what transpired at their session yesterday. Then for the rest of the 
time, we’ll have audience questions. We’re going to start with Joe White from the NRL whose 
session was entitled “Real Time Automated Systems.” 

JOE WHITE (NRL): We had a good crowd yesterday, we had about 30 or so people, pretty 
much a roomful. And we started off trying to define what a real-time automated system was, 
and basically came up with this kind of thing — that it was system that provided time or 
frequency, or both, to the user specification actually in real time; that it might include some 
sort of a historical calibration feature; but that basically what he wanted, he got out of the 
spigot right when he asked for it. 

The other thing about the automated part, in particular, was there was not a frequent operator 
action required. In fact, in many cases, there wouldn’t be an operator around it at all; we 
talked about fully-unattended and remotely-controlled type applications. The applications of 
these systems would typically include things like national time scales, remote time stations, and, 
as embedded pieces of equipment in military systems, telecommunication systems. 

The class of performance that we were looking at for these systems, as far as time went, was 
on the order of 100 ns or better time accuracy; frequency accuracy to at least a part in 10 n ; 
and again, this depended with some of them being as good as part in 10 14 ; and frequency 
stability, ranging from hydrogen maser systems, like a radio observatory system, to parts in 10 13 
at a second to other systems that might only be in parts in 10 13 at a day. The other factor in 
this performance was that we required a synchronization to some national standard, or at least 
some network standard, and usually by a GPS or two-way time transfer measurements. 

When we talked about the measurements, one of the things that came out that people 
thought was important there was that the measurements be accurately time-tagged when they’re 
collected. Those of you that played with these systems, particularly things run by PCs, know 
that those time tags can often be in large error. And we talked about means of doing that, 
including having a hardware clock in the measurement system that provided very accurate time; 
or, alternatively, using one of the telephone or network time synch mechanisms for the control 
computer to keep it on time to the millisecond range. 

Naturally, we all wanted nice quiet, unambiguous measurements, and we decided, in general, 
that meant making time measurements — or frequency measurements, I should say — at 
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5 MHz to get the smoother performance there. While one pps measurement was certainly 
necessary for things like GPS measurements, two-way time transfer measurements, in general, 
there were a lot of problems with those, as far as having a clean pulse to measure, establishing 
the right to triggering levels, the effects of long cables, those kinds of things. 

We next talked about distribution systems, and we started off talking about the effects of the 
local environment on the distribution; that is, that the temperature, humidity, those kinds of 
things, often had an effect. The other thing that went with that is having a good way of 
connecting to it, that the connectors that were used and the types of cable were very important 
to achieving a good distribution, that just the distribution amplifier alone didn’t really cover 
everything. We were typically looking for isolation of at least 100 dB between ports, and also 
100 dB from output to input, which we have seen some systems not doing. 

The other thing that was kind of interesting in distributions, we talked about widely-distributed 
systems, for instance, a communications network where the real-time automated system wasn’t 
two racks sitting on one site, but a rack here, and a rack 100 miles away, and another that 
really is — in the terms of the way that system worked, really that was the system that they 
wanted to have as a real-time automated system. So sometimes the whole interconnection and 
distribution gets to be a pretty large problem. 

From there, we went to software, or actually, robustness, which got us to software pretty quickly. 
Sam Stein gave what I thought was a nice definition of robustness; and that is that the small 
error in the system caused only small problems to the system operation. For instance, losing 
one device in the system shouldn’t cause it all to die. That got us immediately to computers, 
and we decided there that you really need both stable user software, the specific software you 
wrote to make that system work, and stable underlying operating systems for the computer 
itself. A lot of times that’s UNIX or OS-2, or something like that; that there often was great 
peril in changing versions of operating systems that ran the whole thing. 

Also, in the robustness area, we talked about the trade-off between single point failures and 
the things that you do to try to avoid single point failures; there is a point of diminishing 
marginal returns as you add more and more redundancy and put in the switches to put the 
redundant sides together, that often you actually got to a system that was worse than what you 
started with; and that one of the solutions to that was to encourage your user of the system, 
the people that take the time and frequency outputs, to design their systems to be tolerant of 
small glitches; so that you really had a robust system in total, not just in the time and frequency 
part, but also in the piece that used the time and frequency. 

We ended the robustness part with trying to define how you put robustness in the specification. 
And I think we came to the conclusion it was difficult to define that. There are really two 
problems. One was that you had to define what the users environment was, because what was 
robust for one environment may not be robust at all for another. And the other problem was 
that it’s awfully hard to think of everything that can go wrong. You try to come up with very 
blanket-type statements that will cover everything; and when you field the system, you almost 
always find out there is something you left out. So I think we wound up agreeing that we had 
a difficult problem that we didn’t quite know how to define. 
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We ended up talking about maintenance and testing. The general consensus, as far as 
maintenance went, was that we thought that systems should be maintained generally at the box 
level in the field; that the modern hardware is simply too complex to deal with in the field; 
that no matter how well you train your technicians, it’s very difficult, it’s very expensive; that, 
in general, you ought to have a lot of spares and rotate them around and let the manufacturer 
or at least some highly-trained depot deal with most of those issues. To support determining 
when we had problems, we talked about built-in tests; and also, about a remote diagnostics 
capability. 

That’s pretty much it. 

RAY FILLER: Thank you. Next, we’ll have Dick Sydnor from JPL. His session was entitled 
“Real World User Requirements.” 

RICHARD SYDNOR: None of us seemed to know exactly what that title meant, so it took 
a little bit to get the thing going and we sort of wandered over a large area. 

The first part of the discussion was sort of a deja vu; we have talked about this many times 
in the past, and it’s the problem of communication between the supplier and the user. We 
had a number of examples of a user having incomplete specifications. He forgets that he’s 
going to take the spacecraft oscillator and launch it. So it has to have a shock and vibration 
specification, and he’s left that out. Then he comes and says “Gee, it broke.” That kind of 
thing happens more often than you might think. 

Also, on the other hand, sometimes the oscillator or frequency standard supplier doesn’t have 
a really complete set of specifications in his catalog. He doesn’t say what effect vibration has 
on phase noise, for example; so sometimes it’s difficult to figure out exactly what this particular 
item is going to do in your environment. 

It was suggested that the supplier whongets a set of specifications from a user should question 
those requirements. He knows more about his oscillators than the user does probably. And if 
something looks a little bit awry, then he should question that and find out if the user means 
what he says, or if he has left something out. Many times the user is not very familiar with 
the oscillator and how it works, and its problems. And so there is a misunderstanding of what 
some of the specifications need. So there is a need for user education. 

But who is responsible for that? That was kicked around for quite awhile. And John Vig had 
some comments about availability of literature that would outline tests and give information 
to the user. Some users say there is no information out there. And it just means that they 
haven’t really looked very much. 

I think the best suggestion, but probably the hardest to implement in that area, was that the 
supplier should be involved in the procurement from the very beginning. And that’s a little 
hard to do with the present legal situation where you have competitive bids, how you get all 
these suppliers involved in it. But still, it looks like the most logical way to handle some of 
those problems. Those problems have been discussed many times in the past, and no solution 
has been forthcoming as yet. 

Then we sort of wandered away from that area, and we started talking about problems, 
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various specific problems in terms of, say, distribution systems, time delay variations in cables, 
fiberoptics, how you stabilize fiberoptic systems, good connectors, that sort of thing; how you 
make sure that if you have a large network and you distribute it in time to, say, a bunch of 
people that are all various distances away from your main control clock, how they all have the 
same time, rather than varying all over the place due to the length of the cables. We had quite 
a bit of discussion on that. 

Somebody asked what do the margins mean in a specification; and there is 90 percent probability 
that it will do such-and-such. Do people really understand that? I think the answer on 
that one was that nobody really knows exactly what is meant by that margin statement, and 
most people would rather have a specification that says it’s guaranteed to do no worse than 
such-and-such. 

There were some comments about various problems with crystal oscillators. It was brought to 
our attention that crystal oscillators stored at a very low temperature sometimes comes back 
out of that as a completely different crystal oscillator than the one you put in. There are aging 
rate changes and everything else. 

That pretty much handles it. We had a large group in here. I would say the room was half 
full. But we had only five or six people that really contributed. Thank you. 

RAY FILLER: I’m sorry that our third session chairman is not here. But if anybody who was 
there wants to make some comments, that’s fine. 

We’re going to open the floor now to anybody for questions, comments, discussion of any sort, 
on this topic or maybe any other. 

GERNOT M. WINKLER (USNO): It may be useful to elaborate a little bit more on your 
comments about margins and specifications. It’s a problem which comes up over and over 
again; and that is that a system, whatever kind, has certain system performances; and then 
you have accidents. The two come from different distributions. And I think they should be 
separated. 

It makes no sense to include accidents in a system specification; if you separate them, you 
can put a limit on how many you will tolerate per year, or per month, or whatever. But the 
system should be characterized after these accidents have been separated; because otherwise, 
you characterize two different processes with one number. 

RICHARD SYDNOR: The margin discussion would have more to do with things like radiation 
exposure; after a certain number of rads of radiation, the probability is ninety peercent that 
it will be within a certain range. That sort of thing is typically what you get with radiation 
exposure, for example. The specs you see in manufacturers’ catalogs on something says, for 
example, at a second, a part in 10 13 . To me, that means that it’s no worse than that, under 
any condition. A benign environment, obviously. 

But if you are talking about systems, then you have to know not only, say, an upper limit, 
you have to know what the spread, what the distribution of the things are. And that’s not in 
the manufacturers’ catalogs. And many of them probably don’t even know what it is. Some 
manufacturers will supply that information, if it’s available, and they give it in terms of a 
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histogram or something like that, a performance of the different ones that were produced. And 
that’s essential if you’re doing a system design. But that wasn’t discussed during our meeting. 

DICK KLEIN (LOCKHEED AT KENNEDY SPACE CENTER): One of the things 
we’ve noted with more than one vendor, they’ll take the specification, particularly a short-term 
specification of an oscillator, and publish it as the short-term specification of the GPS receiver, 
ignoring the pertubation of the circuitry within the receiver itself. And we found that to be a 
problem in more than one vendor. Particularly one problem, you could almost see a IRIG A 
on the 1 MHz output. And it turned out that they were able to correct it. But apparently, it 
wasn’t tested at the factory, only the specification that the oscillator manufacturer gave. 

JOE WHITE: I think that happens. 

FRED WALLS (NIST): One of the limitations and specifications for almost all oscillators 
and synthesizers, and things of that sort, is a lack of specification for AM noise. And in 
many system applications, it is the AM noise that limits noise floor for residual measurements 
on amplifiers and other things; you have AM to PM conversion in your amplifiers and on 
mixers and on non-linear things. You can have two oscillators with the same phase noise, 
and yet different AM; and one will work and one won’t work. And so, we need to raise the 
consciousness of both manufacturers and users to insist on AM noise specifications. 

RICHARD SYDNOR: That’s a good point. Many manufacturers don’t even know what the 
AM noise performance of the oscillators are, because they measure just the phase component 
and not the AM component. 

JOHN VIG: In our experience in the Army, many of the problems that come to us originate 
from the fact that people who are assigned the job of writing a specification, and this often 
involves major systems — people just sit down and write specifications in isolation, without 
regard to what’s been written before; and they invent their own definitions, invent their own 
way of measuring certain parameters for which others have already worked out the details. For 
example, Ray came back from a meeting recently on a major radar system. He was asked to 
review the specification for the oscillator, and he found several things that were just basically 
wrong with the specification; one, of which, was that a frequency of zero — 

RAY FILLER: Yeah, a frequency of zero. The frequency aging specification was plus or 
minus F zero, I think, or something. 

JOHN VIG: Yes, totally nonsensical specifications are being written by people who don’t know 
what they’re doing. And this is for multi— billion dollar systems. So I think the manufacturers 
probably could perform a service by including in their literature a list of existing specifications 
that people could at least start with. There are IEEE specifications, there are military 
specifications, there are IEC specifications; we have a set of definitions in a CCIR 1 glossary. 
That means they are all internationally recognized and accepted documents. 

If somebody has a job of writing a specification, it’s so much easier to go to the existing 
document and just call out a paragraph of an existing document rather than to sit down and 
scratch your head, ‘How should I define ‘aging,’ how should I define ‘phase noise?’ ” and 

’international Radio Consultative Committee, now named the ITU R. 
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invent things when there is no need for that. 

JIM DeYOUNG (USNO): I think you said that Dr. Hellwig wasn’t here. I took some 
notes, and so maybe I could give a short synopsis of what happened in our group, “User 
Environmental Effects.” 

Dr. Hellwig introduced a document that is going to be published, I believe, in the spring of ’95, 
discussing user environmental effects, including radiation, acceleration, temperature, humidity, 
et cetera. It’s going to be IEEE Standard 1193-1994. 

Our group — after Dr. Hellwig gave this little bit of introduction to get us going, he also 
introduced three areas he thought were important, which is fitness of use. Does your device 
or system really meet your requirements that you originally had formed? He had another 
consideration: “How do I characterize this?” or, optimize the design is the bottom line on 
that. And then he discussed liability and survival of systems that are important in your timing 
or frequency. 

We talked about complex systems, as that’s getting to be a problem. We have specifications on 
individual devices, but then how do you merge those specifications on those devices and get a 
global picture of how the system is going to perform? We decided communication; in my few 
years in PTTI, that’s always been one of the things we discussed in most of these forums, is 
communication as one of the most important things that can happen. 

There were a few specifics that we discussed, and that happens to be related GPS clocks 
on board the satellites. At least one gentleman — I’m not sure of his name — mentioned 
something about the Block II— R clocks where, in the early incarnations of the GPS clocks, 
they were doing frequency stability measurements; I believe it was temperature variation in a 
vacuum. Those tests were done and they found some problems with specific clocks. But those 
tests aren’t even being done now in the Block II— R clocks. So that was pointed out as possibly 
a problem. 

Then one final thing we discussed was that the design materials and the components are 
very important; therefore, you want the highest quality of those things. That’s pretty much 
everything I have in my notes from that group. 

RAY FILLER: Anybody have anything else to add to that or to any other topic of discussion? 
Thank you. 
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